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@ Computer display adaptor interfacing. 



@ A programming interface is provided In a computer graphics system which allows plural hardware 
display adaptors to be upgraded and enhanced without correspondingly upgrading and rewriting 
display specific device driver code for each separate program application using the graphics system. A 
resource library with a standard programming interface, but specific to each display adaptor is 
included, as well as display driver code for each adaptor. Functions necessary to service the graphics 
model embodied in the program application are configured as device driver models and also are 
Included within the interface of the present invention. Initially, the (unctions provided in the resource 
library are dynamically bound to expose the functionality of the desired display adaptor. A second level 
of dynamic binding is implemented to bind the program application with the display specific code and 
graphic models being utilized. In this manner, numerous combinations of program applicatk)n8 and 
display adaptors can be used without providing an interface for each possible combination. 
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COMPUTER DISPLAY ADAPTOR INTERFACING 



This invention relates to a system and method for 
interfacing computer display adaptors. The present 
invention provides a system and method for interfac- 
ing t}etween at least one program application and a 5 
plurality of hardware display adaptors. In particular, 
the program application can comprise a graphics 
package. A programming interface layer, positioned 
between the display subsystem portion of an operat- 
ing system and the specific display adaptors being io 
utilized, combines a number of device independent 
graphics models and device dependent display driv- 
ers such that the hardware and software capabilities 
of the overall system can be optimized. This combi- 
nation of graphical models and device drivers is is 
realized through a procedure known as "dynamic 
binding." 

Originally, one or more independent drawing 
routine packages, such as GSL X-Windows, or 
graPHIGS (all which are products of IBM Corp.) were 20 
utilized on the display subsystem. The packages ten* 
ded to operate in a space sharing and time sharing 
mode in which each package utilized the full screen 
and in which the time sharing was controlled by com- 
mands input from the user. There was no sharing of 25 
the screen by two packages. 

If more than one type of display adaptor could be 
installed on the display subsystem, each independent 
drawing routine package would support its own device 
dependent control of the display adaptor. The drffe- 30 
rent types of display adaptors would generally have 
unique means of entering hardware commands and 
unique means of representation of graphical data. 

The independent graphics routine packages each 
maintained their own "model" of graphics. The 3S 
method of passing data and commands and the 
functionality of the programming interface to the 
routines were unique to each model. The uniqueness 
of the nKxiel determined pronounced differences be- 
tween the ways the packages would implement 40 
device dependent control of the specific display adap- 
tors. 

A specific prior art graphics package provides an 
application interface (API) with several device drivers 
which are incorporated therein and associated with a 45 
specific display adaptor. These device drivers are 
dependent upon the type of display adaptor being 
utilized. Additionally, every package present must 
have a display drlverfor each display adaptor present 
Therefore, a problem arises when it is desired to so 
change a display adaptor, or add an additional display 
adaptor, since the device drivers are actually con- 
tained within the independent graphics routine pack- 
ages and each package would have to be updated 
with the new device driver code. Another problem 55 
arises in that there Is a need to constiuct a number of 



device drivers equal to the product of the number oT 
packages times the number of types of devices. 

Prior art systems are limited in that for each new 
or updated device, each of the graphics packages 
present must also be changed. This requirement for- 
ces a software vendor to rewrite the code contained 
in the graphics package for each new or enhanced 
device. Alternatively, the vendor must teach a 
software user to rewrite the code, which may cause 
problems with regard to proprietary and confidentiai 
information. Another problem with the prior art system 
exists in that any new functionality, provided by added 
devices (display adaptors), is limited to the installed 
graphics model. For example, if an enhanced type of 
display adaptor was added to a prior art system using 
a GSL graphics model, the user would not be able to 
use the new features except as penmitted by GSL 

Therefore, it can be seen that there is a need for 
a graphics interface which provides flexibility between 
the graphics applications and the display adaptors. It 
would also be advantageous to provide an interface 
which allows multiple graphics rrxidels to operate in 
conjunctton with a plurality of device dependent driv- 
ers such that the full capability of the graphics models 
and display adaptors can be exploited, without 
experiencing the redundancy problems present in the 
prk)r art 

The present invention provides a system for Inter- 
facing between at least one program appiicatbn and 
a plurality of hardware display adaptors, each having 
specific functions, comprising : 

a library of resource functions (40) containing 
data defining functions provided by said hardware dis- 
play adaptors ; 

a plurality of device interfaces 10, 20, 30, 
matching the capability of said program application ; 
and 

means for associating selected resource func- 
tions with one of said device interfaces, for a particular 
combination of a display adaptor and sakJ prograrh 
application. 

Such a system is able to reconfigure itself by 
dynamically binding an applk:atk)n such as a graphics 
package with ttie required RMS features and device 
specific model instance driver for the display adaptor 
being used. This process of dynamic binding uses a 
database or equivalent tabular representation to : (1) 
locate the specific graphics nrradel desired ; (2) ret- 
rieve this n>odel ; and (3) bind the nrK>del to the (a) 
device driver code for the specific display adaptor 
being utilized, and (b) the RMS function required by 
ttxe particular graphics model. 

A preferred embodiment of the present invention 
utilizes two levels of dynamic binding, the first being . 
within the RMS. The RMS functions present are inde- 
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pendent from the graphics model being "sed and 
hence it is necessary first to dynamically bind the 
device driver code necessary to provide the color 5 
resource, font, adaptor resource, and the like, 
required for the specific graphics model. The second 
level of dynamic binding occurs between the dynami- 
cally bound ms, the desired graphics package and 
the device specWc model corresponding to the dis- io 
play adaptor being utilzed. 

There is further provided a method of interfacing 
between at least one program application and a 
plurality of hardware display adaptors, each having 
specific functions, said method comprising the steps is 

°^ ' providing a library of resource functions (40) 
containing data defining functions provided by said 
hardware display adaptors: 

providing a plurality of device interfaces (10. 20 
20. 30) matching the capablity of said program appli- 
cation; and 

assocBting selected resource functions with 
one of said device Interfaces, for a particular combi- 
nation of a display adaptor and said program appli- 25 

cation. 

The present Invention will be described further, by 
way of example only with reference to an embodi- 
ment thereof as lluslrated in the accompanying draw- 

30 

Ings in which : 

Rgure 1 is a block diagram representing a pnor 
art graphics display subsystem ; 
Figure 2 is a block diagram Olustrating a graphics 
display system including the programming inter- 
face of the present invention ; 
Figure 3 Is a diagram showing the components of 
the graphic adaptor interface of the present 
Invention and their relationship to the display 

adaptors; ..... u 

Figure 4 is a table illustrating the means by which 40 
the present inventten locates and associates the 
models and other componente. with the display 
adaptore during dynamic binding ; 
Figure 5 is a block diagram showing the graphics 
adaptor interface of the present invention ; and 45 
Figure 6 is a block diagram depicting another 
embodiment of the present invention wherein a 
single graphics package is capable of providing 
an interface for a plurality of display adaptors, or 
a plurality of device driver interface nwdels. so 
Referring to Figure 1. a prior art graphics appli- 
cation programming Interface system is shown. Three 
separate application programs 51. 52. 53 are present 
Application 51 Is two^llmensional (2D), whereas 
applications 52 and 53 correspond to firet and second ss 
three-dimensional (3D) applications. Next, a set of 
graphics packages 56. 57, 58. embodying models 10. 
20. 30 are shown, each supporting applicatons 51. 
52. 53. respectively. These packages provWe a prog- 
ramming hlBrface between a program application 



and display dependent device driver sets 70, 71, 72 
as discussed in more detail below with reference to 
the present invention. It can be seen from Fig. 1 that 
each graphics package 56. 57. 58 includes a device 
driver set 70. 71 . or 72. which must contain code that 
is dependent upon each display adaptor present 

The programming interfaces to device driver sets 
70 71 . and 72 are not necessarily the same, and there 
is not any particular requirement ttiat all of the device 

dependent sections within a device driver have the 
same programming interface. In this exemple. display 
adaptore 1. 2, 3, 4 are provided with corresponding 
dependent display driver code 81 . 82. 83. 84. 85. 86. 
87. 88, 89, 90, 91. and 92. 

Therefore, the redundancy of the prior art system 
of Fig. 1 is apparent That is. each device driver set 
70 71 72 must contain code specifically written for 
each display adaptor present. Thus, device driver set 
70 includes four sets of code 81, 82, 83, and 84 ; 
device driver set 71 includes four sets of code 85, 86. 
87 and 88 ; and. device driver set 72 includes four 
sets of code 89, 90. 91. and 92. There are twelve sete 
of code in all. which is the product of the three models 
times Uie four types of display adaptore. 

it can be seen that by adding or altering (by 
upgrading, or the like) any of the display adaptore 1. 
2 3 4 the corresponding device driver code 81. 82. 
83 M. 85. 86, 87, 88. 89. 90, 91. and 92 (contained 
in device driver sets 70. 71 , 72) must also be altered. 
ConsequenUy. if display adaptor 4 (for example), 
virere upgraded, then graphics package 56. 57, 58 
would also need to be updated such ttiat the display 
driver specific code 84. 88. and 92 would correspond 
to the upgraded adaptor 4. The desirability of eliminat- 
ing this redundancy, in order to Improve efficiency, is 
readily apparent 

The structure of tiie graphics adaptor interface 
(GAI) of the present invention will now be described 
with reference to Rgure 2. Applications 51 . 52. 53 are 
shown and represent the same program applications 
as prevtously desaibed. That is, reference numeral 
51 represents a 2D application and reference numer- 
als 52 and 53 represent firet and second 3D appli- 
cattons. Also, display adaptors 1. 2. 3. 4 are shown 
and represent the same componente as described 
with regard to Figure 1. 

Applications 51 , 52. 53 all utilize specific indepen- 
dent graphics drawing routine packagea 56. 57. 58 
(graphics packages, or packages) whteh embody dif- 
ferent graphical models. The application program- 
ming interfaces of these packages (APIs) implement 
their respective graphics models by calls to the 
Graphics Adapter Interface (GAI) 60. which incorpo- 
rates device driver programming interface (device 
interface) models 10, 20 and 30. The programming 
interface of ttie device drivere Is constructed to match 
the graphical model used by ttie various graphics 
packages 56, 57. 58. The GAI device drivera take the 
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place of the device driver interfaces 70, 71, 72, as well 
as the device specific code 81 . 82, 83. 84, 85, 86, 87, 
88, 89, 90, 91, and 92. GAI 60 provides a common 5 
Interface t)etween the packages 56, 57, 58 and dis- 
play adaptors 1,2, 3. 4. 

In addition to the graphics device driver models, 
or device Interfisces, 10, 20, 30, a resource manage- 
ment services (RMS) library 40 is included, which is io 
a library of routines which support the functions and 
characteristics, i.e. resources available on specific 
display adaptors 1, 2, 3. 4. In addition, the RMS library 
40 provides a standard means for packages to select 
which model of device driverwill be used to implement 15 
the graphics functtons. These device driver interface 
models 1 0. 20, 30 are each a library of functions. I.e., 
a group of related routines which conrespond to and 
implement the specific 2D, 3D, or other functions 
required within a device driver by graphics packages 20 
56. 57, 58 under control of applications 51 , 52, 53. For 
example, the 2D model 10 is based upon the X-Win- 
dows product whereas 3D models 30 and 20 are 
based upon the Silicon Graphics, Inc., GL package 
and the IBM graPHIGS product Therefore, it can be 25 
seen that the interface models 10. 20, 30 included 
within GAI 60 are a balanced collection of functions 
required by the specific models of different graphics 
packages. The aforementioned products are only 
used as examples and do not exclude other such 30 
functksns from the scope of the present Invention. 

The RMS 40 library provides the mechanism by 
which applications 51, 52, 53. running within indepen- 
dent processes, manipulate the specific display adap- 
tors 1 . 2. 3, and/or 4. as is desired by the application. 35 
such that all of the avaOable characteristics of that 
adaptor are utilized. RMS 40 is organized on the basis 
of resource headers, attributes and procedures. A 
header contains pointers which direct an application 
to the attributes and procedures of a resource. A 40 
header may also contain pointers to private data and 
to extenskins. An attribute Is defined as the data des- 
cription of a resource. A procedure is a function 
pointer that operates on a resource. The combination 
of resource headers, resource attributes, and 45 
resource procedures is an organization typical of 
those used for object-oriented programming. Func- 
tions which may be included within RMS 40 of GAI 60 
may initialize, reset or update the previously noted 
functbn pointers. so 

Each separate display adaptor 1, 2, 3, 4 may be 
capable of certain characteristics which enable the 
display adaptor to provide differentfundtons to a user 
program application and may vary between adapt ers. 
The RMS 40 library provides a standard device driver 55 
progranrvning interface to expose these functions to 
the graphics packages. The functions are embodied 
as RMS resources. These functions include: (1) 
monitor, whk:h enables the communicatk>n between 
the display adaptor and a display (CRT) ; (2) group, 



the ability to have an object on a display adaptor such 
as set of planes, but may include cursor and color 
maps ; (3) window, infomnation regarding application 
clipping information, active groups and active buffers; 
(4) window geometry, informatksn regarding the size 
and configuration of any windows In a windowing 
environment; (5) cursor, information regarding a 
screen locator : (6) color map, whk:h is a set of color 
specifications for a specified group ; (7) font, which la 
a definitton of operating system fonts (assortment of 
characters) In raster, vector, or outJine format ; (8) 
model, which specifies which type of device driver 
interface the package requires for compatible oper- 
ation with the graphics model embodied in the API ; 
and (9) adaptor, which is the highest level resource 
and which contains attributes and procedures used in 
creating and controlling the other resources. 

The aforementioned resources are generally 
included in display adaptors which are contemplated 
to be used in conjunction with present Invention. How- 
ever, other resources may t>e available and as such 
the present Invention is not limited to a system having 
only those resources listed above. 

Each of display adaptors 1 , 2, 3, 4 may or may not 
utilize the same number and types of resources, l.e. 
each display adaptor will have its own assodated 
RMS 40 library of function. Therefore, the resources 
which are capable of being exploited by a specific dis- 
play adaptor must be configured and bound together 
when this specific display adaptor is utilized by a pro- 
cess within a program application. 

In order to accomplish the configuratk>n of display 
adaptor specific resources within RMS 40, a method 
of creating a path from RMS 40 to this specific object 
file of the resource required is utHlzed. in the present 
invention, dynamic binding is the mecha nism by 
which RMS 40 configures resources into a display 
adaptor specific library of function. It should be noted 
that other methods of linking these resources, such as 
shared libraries, are contemplated by the scope of the 
present invention. 

Dynamic binding is a means of linking all of the 
resource codes and model specific libraries to the 
Independent graphics drawing routine packages. This 
linking is implemented by means of operating system 
utilities, at the time of execution of the applicatbns 51, 
52. 53 as opposed to the time of compilatbn of the . 
application or of the graphics package 56. 57. 58. 
Dynamic binding in GAI 60 is accomplished by rules 
contained in the device specific RMS library 40 using 
data supplied In the RMS adaptor resource by either 
the application or the API. Each display adaptor 1, 2, 
3, 4 will have its own set of required RMS 40 library 
files (see Figure 5). 

When the API desires access to the device driv- 
ers, a general GAI RMS call is invoked, to which is 
provided ttie ID of the display adaptor 1 , 2, 3 or 4. The 
ID and other parameters from the call are used to 
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access a look up table or configuration file and find a 
file system path to the required resource object f^ie. 
The object file of the resource is then loaded and he s 
entiy point code Is executed. In this manner, the 
dynamic binding of the RMS library 40 is accom- 
plished for a particular device to a particular package 
56. 57. or 58 for use by its respective application 51 , 

^^'when the package desires additional 
functtonality not in place in the RMS library 40 it uses 
the RMS model resource to specify the model of QAi 
device driver 1 0. 20. or 30 required by the API. The 
RMS library 40 utilizes this model data to execute a is 
second dynamfc bind, loading the device-and mode^- 
speclfic GA1 device driver and binding it to the pack- 
age. The RMS library utilizes a similar lookup table or 
configurationfile tofind the path to the required mode 
resource object file. The object file of the mode! 20 
resource is then toaded and the entry point code is 
executed. In this manner, the second level of dynamic 
binding of the package to a devtee specific, model 
specific device driver is accomplished. 

An example of the dynamic binding which occurs 2S 

within RMS 40 wll now be discussed, allowing one 
skilled in the art to easily comprehend how to invoke 
this process (see Figure 2). 

For example, assume applicatfon 51 implements 
a process to be displayed by a display adaptor 1. onto 30 
a display such as a CRT. or like (not shown). First, ttie 
package 56 would determine thatdisplay adaptor 1 is 
required. The package 56 would dynamically bind 
with the RMS library 40 which supports display adap- 
tor 1 The outcome of the binding would determine 35 
which RMS library resources and funrtions are 
required by display adaptor 1, and dynamically allo- 
cate these resources, e.g. the cursor resource, font 
re3ource.andcolormapre3ourcesasrequiredfordis. 

play adaptor 1. Second, since application 51 uses a 40 
2D package. 2D model 10 Is required to support the 
package. The package 56 ufilizes the model resource 
of the RMS library 40 to dynamically bind to the ZD 
model GAI device driver 10 (see Figure 3) for the dis- 
play adaptor 1. Thus, application 51. is able to wnte 45 
to display adaptor 1 and utilize all of the character- 
istics associated with that particular hardware device. 

Further. shouW a user of application 51 decide to 
write to display adaptors, then the package 56 would 
Z«t the dynamic bind with the RMS library, this so 
time for a devtae specinc instance RMS library 42 sup- 
porting display adaptor 3 (the programming interface 
to each RMS instance is identfcal). The pactege 56 
then manipulates the model resource of RMS libranr 
42todynainicanyblndtothedevlcs8pecrfic2Dmodel ss 

device driver 12. whtah driver supports display adap- 
tor 3. The programming interface to 2D device driver 
10 and 2D devtoe driver 12 are Wentical. with only the 
device spedfteoutputof the routines vaiying. It can be 
seen how a multitude of combinattens exist between 



applications 51. 52. 53. display adaptors 1. 2. 3. 4^ 
model specific device drivers 10-13. 20-23. and 30- 
?3. and packages 56. 57. 58. thereby allowing each, 
application the abBity to utilize which ever display 
adaptor characteristics are most desirable in a given 

situation. , .... . 

Concurrent use of multiple models from within a 
single process woite because models are stateless. 
Any required state infomiation is contained within 
resource attributes, which are shared by all models, 
or passed as parameters to the procedures^ 

The components of GAI 60 will now be further 
described with reference to Figure 3 which is a block 
diagram showing possible combinations of the comix) 

nents contained within GAI 60. The output from GAI 
60toeach display adaptor1.2.3.4i8Shownsuchttiat 

the components required to be bound, for each adap- 
tor to operate with a specific graphical model (as 
embodied by packages 56. 57. 58). can be deter- 
mined. Particular RMS libraries 40, 41. 42. 43 cor«>- 
spond to display adaptors 1. 2. 3. 4. respectively and 
provide the required functions as previously discus- 
sed. Two-dimensional model specific device drivere 
10 11 12 13 directly relate to display adaptors 1. 2, 
3 4 respectively, and specific 3D model device inter- 
faces 20. 21. 22. 23 respectively relate to display 
adaptors 1. 2. 3. 4. Finally. 3D model 30 includes dis- 
play device driver models 30. 31. 32. 33 whichalso re- 
spectively relates to display adaptors 1 . 2. 3. 4. For 
each new display adaptor In Fig. 3. the several dev.^ 
specific instances of a particular model-spear« 
device driver library have an Identical programming 
interface. Thus, an independent drawing roubne 
package need only implement one device dnver pro- 
gramming interface, to gain access to a vanety of 

devices. ... . . 

An example of the components which must be 
dynamically bound under given conditions will now be 
described with reference to Figures 2 and 3. A^ume 
application 53 (Figure 2) desires to write to display 
adaptor 2. The package 58 loads the RMS libraiy and 
is dynamically bound to RMS library 41. since display 
adaptor 2 Is being used. Because application 53 
utilizes the GL package 58. and since the GL package 
58 embodies the graphical model 3D-M2. then ttie Gl. 
package 58 uses RMS library 41 to create a model 
resource and uses the model resource to dynamically 
bind the 3D-M2 device driver 31 with ttie package 58. 
This Is because model 3D-M2 includes the graphics 
functtons required by package 58 and application Kl: 
and the device specific implementation of the 3D-M2 
device driver for display adaptor 2. shown on Figure 
3 as item 31 , converts ttie graphics functions into ttie 
corresponding device specific function provided by 
adaptor 2. Thus, by implementetton of dynamic bind- 
ing between ttte package 58. RMS 41 and graphics 
model 31. applteation 53 is capable of writing to dis- 
play adaptor 2 and utiUzing all of ttie specific functions 
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contained therein. 

Similariy, assume application 51 (2D) desires to 
utilize display adaptor 4. First, an initial level of 5 
dynamic binding will occur between package 56 and 
GAJ 60 to bind the RMS library 43 to the package 56. 
RMS library 43 is the resource iibraiy specific to dis- 
play adaptor 4. Next, the second level of dynamic 
binding will occur between the package 56 and the 2D io 
graphics model 13. Thus, application 51 is now able 
to interface with and write to display adaptor 4 via the 
dynamically bound components within GAl 60. 

It should be noted, that by way of example and not 
limitation, Figure 3 shows two display adaptors 3, 4 15 
which are not capable of perfomiing 3D operations. 
Thus, 3D models 22, 23, and 32, 33 are depicted, by 
dashed lines, as not containing any functional 
routines. However, this lack of function is due to a par- 
ticularity of display adaptors 3, 4, discussed in this 20 
example and not to GAl 60. Should enhanced or 
upgraded display adaptors be provided for original 
display adaptors 3, 4 then 3D nfKKjels would be 
included within the functional capabilities of GAl 60, 
i.e. substituted for 22, 23 and 32, 33. Similarly, should 25 
software be written in the device driver to emulate the 
missing 3D functions of adaptors 3 and 4, then the 
device drivers could be installed in place of 22, 23, 32. 
and 33 such that some functions would be passed to 
the display adaptors 3 or 4 and other functions would 30 
be emulated in the device driver. It can be seen how 
the interchangeabllity and the flexibility of GAl 60 
allows ease of updating, enhancing and substitution 
of display adaptors without imposing a major reprog- 
ramming or re-linking burden on users of this conv 35 
puter graphics system. In the cases descnbed above, 
no change would be required to any application or 
package. 

Another function embodied in GAl 60 and depic- 
ted in Figure 3 is the ease of addition of a new adaptor 40 
into a system in which packages, applications, and 
display adaptors already exist For example, the indi- 
vidual GAl libraries which must be added to accom- 
modate a new display adaptor (e.g. display adaptor 5. 
RMS library 44 and device drivers 14, 24, 34) can be 45 
written independently and without regard to each 
other or to which packages 56, 57, 58 will use them. 
Similarly, no changes at all are required to the pack- 
ages or applications thenrueives, to use the new dis- 
play adaptors. This is in direct conbast to the prior art so 
shown in Rgure 1, in which new device drivers would 
be required in each package to support the new 
device. Although a single display adaptor 5 and 
associated RMS library 44 and device drivers 14, 24, 
34 have been added in the previous example (and ss 
shown on Rg. 3), it should be understood that a virtu- 
ally unlimited number of display adaptors may be 
added, without requiring any changes to the existing 
components, as described above. 

Figure 4 illustrates a typical look up table and the 



commands used by the present inventton to provide 
the dynamic binding that occurs within GAl 60. More 
particutariy. the location and nanrie in the file system 
of the operating system is stored in the table. The indP 
vkiual GAl instances of device specific code are each 
listed in the table. Additional columns associate each 
piece of code with the correct adaptor and model. In 
the table, the convention of assigning value 0 to the 
model column denotes the RMS library ; 1 denotes 
the 2-D model device driver programming interface ; 
2 denotes the 32D-M1 device driver programming 
interface ; and, 3 denotes the 3D-M2 device driver 
programming Interface. Note that both the adaptor 
and the model entries must both be con-ectiy matched 
In order to find the proper device specific device driver 
10, 20, 30. Matching both values is accomplished by 
the analogous two layer dynamic bind. 

The exemplary table of Figure 4 corresponds to 
the components shown In Figure 3. It can be seen that 
the first line corresponds to the resource manage- 
ment services functions (in this case RMS 40, 
associated with display adaptor 1 and noted as adap- 
tor 1, model 0). Further, display adaptor 1 is capable 
of displaying 2D and 3D applications and therefore 
includes models 2D, 3D-M1, and 3D-M2, listed as 
being at adaptor 1, models. 1. 2, 3. respectively. Simi- 
lariy. adaptor 2 is capable of utilizing 2D and 3D appli- 
catbns and contains the same entries as does 
adaptor 1. Of couree, the adaptor specific display 
driver code and RMS code 41 will be different for 
adaptor 2 than they were for adaptor 1. 

The lack of the capability of display adaptors 3 
and 4 to accommodate 3D applications is apparent 
from Figure 4. Only two entries are included for each 
of adaptors 3 and 4, which are the RMS and 2D 
entries. Note that the absence of an entry for a par- 
ticular model and particular adaptor can be exposed 
to applications, to enable them to select which pack- 
ages are suitable. SimSariy, the packages themselves 
can examine the table and detemfiine which graphical 
model support Is available on the display subsystems 
for adaptors of interest The RMS library model 
resource provides a "Query Model' procedure to 
assist in this examination. 

Figure 5 is a representation of the effect of the 
present invention in configuring the GAl with respect 
to each display adaptor 1 , 2, 3. 4. GAl 60 presents the 
same interface to graphics packages 56, 57, 58 for 
each adaptor 1 , 2, 3, 4 as would be accomplished if 
the programming interfaces shown in Rgure 5 were 
actually present The present Invention allows an 
application to change the programming Interface, 
specific to a graphics model, which is bound to a dis- 
play adaptor. It can be reconfigured for each display 
adaptor by issuing a comn^nd to the RMS to destroy 
a model, upon which the dynamic binding previously 
implemented is released. The present invention then 
may, by subsequent dynamic binding, reconfigure 
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GAI eOtoutifee the specifK: characteristics of the r^^^^^^^ 

by a pn^gram applicatton. Also. 9h<««i F^S. -s the 

lidusion of a third (3/rd) party graphKS ^ (N 
Sm equal to the r«xt available referent numeml 
She one used for the last graphics "^ode\.^^^ 

to the system). Rather than adding a "^w^^f 
utilized by existing softv^re packages, a .s f^^^^^^ 

inimHiicB new drawing routine packages wnicn 
L":Sradrremgrap^K:a.,node.th.nthoseshoj^ 

rSures 3 and 5. For such cases, a new dev.* 
model la created, which is the equivalent of 
SS"net;^.oRgure3.App.i«tionsord^w- « 

f«i rwiUne packages based upon the new model 
'SLaTunco^^edU the re<iuirem-t o^^^^^^^^^^^^^ 
device specific code. Thus rt can be seen that by 
dynamically binding the components of GAI 60 a vtf 
S un Jited number of adaptors can t« used J .o 

coninction with plural 9^^^^ ^^^^"^^^'JaZ 
"a the adaptom can be upgraded and enhanced by 
^Ing a'single installadon of - cb^ "^e J^- 
Iim/-rselv orior art systems require a new instai 
STn^f a';Xect file for each applk:a«on being « 
r^^l everyl^anydisplayadap^^^^^^^^^^ 
substituted, enhanced, upgraded, "the 'ike. 

Referring to Figure 6. additional advantages of 
theGi6:Snbe,L.lt«possit.etoin^^^^^ 
oraohlcs packages, such as graPHIGS* 59 (a 3U 
^«nh S orodS provided by IBM Corp.). which take 
SSSTn^ga^SSes of'oA. 60. SM 60 has«« 
flexibility to allow simultaneous J"^^^'^^ 
than one device driver interface model and more ttian 
oM display adaptof.Thus. applicatfon 54. utilEing the 35 
;d^ng inUce of the S^PHIGS. package 
sg/may directly communicate with adaptors 1. Z 3 

and 4 simultaneously. 

The graphics package utflees the GAI RMS 40 

libraries of the specffic display adaptors to aeate 
resources. These graphics packages use the 
S resources to bind to the display device dnver 
^phi«model10.20.30desired.N<.ethat^^^^^^^^^ 
I and 4. as mentkined prevtously in Figures 3 and 4. 
L'Jothavehanlware,upportforgraphl«m«l.^^ ^ 
M1 or 3D-M2 and therefore do not have the aKre 
?in*in9devK»specir,cGAlda>«cedriver^^^^ 
and 23 (Fig. 3) for 3D-M1 and 32 and 33 Ibr 3D-KC. 
?S graphic, package graPHlGS* •nonages 
hartware dependency by Instead utilizing a 2D so 
;S^mod?10whendlsplaylngtoadapto|.3and 

i From the perepectlve of applicatton 54. the pack- 
rnr^PHIGS* 59has provided the abflity to draw to 
SrSlS^^^thTperspec^^ ^ 
il^araraPHIGS+. the GAI 60 has provided a 55 
SS?,^ S^W^dteplay hardware which can sup- 
^SsDci^'^t'yway'ofbind.ngJ^ 
5Sel 20 (Rfl. 6) device drivers for adaptors 1 and 2. 
^dSn.Sxnthepec,pecth,eofthegraph.«^ 
agegraPHlGS+59.th.GA160ha8prov.dedamaans 



for the package to exploit display hardware whjch ^n 
only support 2D operatkins. by way of binding to GAI 
araoS device drivermodel 10 for adaptors 3 and 4. , 
'"tea^^tyofgraphicspackagestomakech^^^^ 
»m«nfl the Graphics device driver models, and to con- 
^S'Srore'Sonemodei.andtoconnectto^^^^^^ 
Sple models at the same time, on ^^^^^^'^'l 
provides substantial flexibnity over the Pnor In 
aSton to the graphics packages, the present inven- 
S^^ P^gram applications the capaM^^^^^^^^ 

vWing thte flexibnity. given the standardized 
pSntming interface of the GAI RMS l^rary^ar^ 
fhe other GAI graphics model devBe dnvers con- 
tained within GAI 60. 



Claims 

1 Asystemforinterfacing between at least one pro- 
gram application and a plurality of harcjirare rhs^ 
Jtey adaptors, each having specific funct«ns. 

• "^''a«Sraryofresourcefunctk,ns(40)contain- 
ing data defining functions provided by said 
hardware display adaptors ; 3- 
a plurality of device interfaces 10. 20. 30, 
matching the capability of saW program applH 

"me"ans for associating selected resource 
functions with one of said devtea inteifaces. for a 
p^cular combinatton of a display adaptor and 
said program appllcatloa 

2 A system as claimed In Claim 1 wherein said lib- 
rarvofresourcefunctionsindudesfirstmeansfor 

dynamically binding selected resource funrtions 
Sraiording to the associated device inter- 
face. 

3 A system as claimed in Claim 2 further including 
te«nd means for dynamically binding sele^ 
resource functions with a selected devwe uiter- 
face. 

4 Asystem as claimed In any preceding dairn com- 
pn^9.foreachsaklprogramappllcation(51 52. 

^, a graphics package (56, 57. 58) apecjymga 
model of graphical function relating to said corre- 
sponding program application. 

5. A system as daimed in Claim 4 wharaln 
graphics package, said devtae interface and Mri 
Sbrary of resource funcltons are dynamtealty 
bound. 

6 A system as daimed in Claim 4 or Claim 5 whe- 
;eiSdgraphicspackaga.3aiddevlceinterface 

S^S^W library of resource fimcUons together 
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constitute a single hardware display adaptor 
interface. 

5 

7. A system as claimed in any preceding claim whe- 
rein said resource functions include monitor date, 
group data, window data, window geometry data, 
cursor data, color map data, font data, model data 

and adaptor data. io 

8. A system as claimed in any preceding claim whe- 
rein said means for associating is adapted to 
associate resource functions for combinations of 
said program application with a plurality of display is 
adaptors to penntt said program application to 
communicate with said plurality of display adap- 
tors. 

9. A system as claimed in Claim 8 wherein said pro- 20 
gram application comprises a graphics package 
dynamically t>ound to a plurality of said device 
interfaces. 

1 0. A method of Interfacing between at least one pro- 25 
gram application and a plurality of hardware dis- 
play adaptors, each having specific functions, 
said method comprising the steps of : 

providing a library of resource functions 
(40) containing data defining functions provided 30 
by said hardware display adaptors ; 

providing a plurality of device interfaces 
(10, 20, 30) matching the capability of said prog- 
ram application ; and 

associating selected resource functions 3S 
with one of said device interfaces, for a particular 
connbination of a display adaptor and said prog- 
ram application. 

11. A method as claimed in Claim 10 wherein said 40 
step of providing a library of resource functions 
includes the step of performing a first dynamic 
binding together of selected resource functions 
according to the associated device interface. 

4S 

12. A method as claimed in Claim 1 1 further including 
the step of performing a second dynamic binding 
of said selected resource functions with a selec- 
ted device interface. 

50 

13. A method as claimed in any of Claims 10 to 12 
comprising, for each said program application 
(51 , 52, 53), the step of providing a graphics pack- 
age (56, 57, 58) specifying a model of graphical 
function relating to said corresponding program 55 
applicatk)n. 

14. A method as claimed in Claim 13 further including 
the step of dynamically binding said graphics 
package, said device interface and said library of 



resource functions. 

15. A method as claimed in Claim 13 or Claim 14 
including the step of forming said graphics pack^* 
age, said device interface and said library of 
resource functions as a single hardware display 
adaptor interface. 

16. A method as claimed in any of Claims 10 to 14 
wherein said step of providing a library of 
resource functions includes the steps of providing 
monitor data, group data, window data, window 
geometry data, cursor data, color map data, font 
data, model data and adaptor data. 

17. A method as claimed in any of Claims 10 to 16 
wherein said step of associating is adapted to 
associate resource functions for combinatk}ns of 
said program application with a plurality of display 
adaptors so as to permit the step of providing sinrv 
ultaneous communication between said program 
application and said plurality of display adaptors. 

18. A method as claimed in Claim 17, wherein sakj 
program application comprises a graphics pack- 
age, comprising the step of provkjing dynamic 
binding between said graphics package and a 
plurality of said device interfaces. 



9 



EP 0 442 676 A2 




FIG. 1 

PRIOR ART 



10 



EP 0 442 676 A2 



Application 
1 

51 




Application 
2 

52 




Application 
3 

53 


X-Wlndows or GSL 
(2-D Model) 

56 


graPHIGS 
(3-D ModeM) 




GL 

(3-D Model 2) 

58 






2-D 

10 


RMS 3-D Ml 

40 20 


3-D M2 

30 


60 

GAI 














Display 
Adapter A ^ 


Display Display 
Adapter B ^ Adapter 


c 

_ 3 


Display 
Adapter D ^ 



FIG. 2 



11 



EP0442e76A2 



LU 

cn 



a> O 
CO Q- 



SO 
-o ^ 



O 
CO 



CMI 



UJ 

o 

CM 



^1 



1X1 



O 

CO 



• 



UJ 
CM 

O 

CO 



SI 



to 

LU 
CO <j) 

0*5 



o 




CO 












51 







o 

CM 



O 
Q 



O 

CO 



CO 
CN4| 



o 

CO 



CM 



o 

cvT 

a 

CO 



CO 

eo! 



o 
o 

CO 



CO 



o 

CO QJ 
C1.Q. 

.22 ro 

05 



eo 

o 
>«1_ 

CO <i> 

OS 



eoll CO 
L ^ 




a> <3. 
CO Q- 



CO 



CM 



21 



CO 



C4| 



CM 



CO 




T- CM 



< 



cn 



CM 



CO 



CO 



CO <D 

03 



12 



EP 0 442 676 A2 



adapter 


model 


object file name 


1 


0 


/usr/lDn/nai/adaDterl /rms.o 


1 


1 

1 


/Li<>r/lnn/nai/adaDter1/2d o 


1 


2 

mm 


/usr/iDD/nai/adaDter1/3dnn1 o 


1 


3 


/usr/lnn/nai/adaDfer1/3dm2 o 


2 


0 


/Lisr/lDD/ciai/adaDter2/rms o 


2 

mm 


1 

1 


/i]<5r/lnnynai7arianter2/2d o 

lUwI/IUIJ/V^QI/a vivify 191 fa/ABV4iV 


2 


2 




2 

Am 


3 


/LiQr/lnn/nai/adanter2/3dm2 o 


3 


0 


/Li^r/lnn/fial/adanter3/rm^ o 


3 


1 

1 


/Lisr/lDD/aai/adaDter3/2d o 


3 


2 


^pmntv^ 
1 iijij ^ 


3 


3 


<einpiy> 


4 


0 


/ijsr/lnn/nai/ariantpr4/rm<5 o 


4 


1 


/usr/Ipp/gai/adapler4/2d.o 


A 
4 


0 


<empiy> 


4 


3 


<empty> 


• 


• 


• 


• 


• 


• 


• 


• 


• 



FIG. 4 

13 



EP 0 442 676 A2 



I 

I 




FIG. 5 

14 



EP 0 442 676 A2 



Application 
4 

54 




graPHIGS + 

(2-D Model & 
3-D ModeM) 

59 






2-D 

10 


RMS 3-D Ml 

40 20 


3-D M2 

30 


60 

GAl 














Display 
Adapter A ^ 


Display Display 
Adapter B ^ Adapter C ^ 


Display 
Adapter D ^ 



FIG. 6 



15 




I 



THIS PAGE BLAHKltWW 



